Separate Application Logic from Architectural Concerns – Beyond Object Services and Frameworks

Application logic refers to the encoding of domain business logic and architectural concerns refer to common non-business requirements on the system, for example, security, transaction, performance, scalability etc. It has been widely recognized that separating application logic from architectural concerns can greatly help reduce the development cost and make the system easier to evolve. Current state of practice relies on object services and frameworks. In this paper we argue why these technologies are not sufficient and propose a new approach based on architecture unification. 1. Separating Application Logic from Architectural Concerns As part of a complete software system, application logic refers to the coding of business process for the problem domain, for example how money flows through a trading system. Usually besides application logic, business applications also require architecture level functions which do not show themselves in the business process, e.g. security and transaction, and properties such as reliability, availability, maintainability, responsiveness, manageability and scalability. A list of proposed architectural properties appear in [4]. Separating application logic from architectural concerns refers to the enabling technology to build common infrastructures to address architectural concerns. With this capability, developers can produce a complete system by only coding application logic and reuse those common infrastructures. This is desirable for several reasons, • It will greatly reduce development cost. Engineers do not need to spend time on building infrastructures to support architecture functions and properties because these infrastructures can be reused from project to project. • It makes systems easier to evolve. Requirement changes on business process and architectural properties can be treated separately. For example we do not need modify application logic code if a system does not scale well. 2. Architectural Functions and Properties We observed that architectural functions and properties are related to following three system artifacts. • Presence of service components. Usually service components will be introduced into the system for certain architecture function requirements. These components typically include authentication server, encryption/decryption library, dynamic load balancer and transaction monitor. • Correct system configurations. Configurations refer to communication paths among system components, i.e. how components are glued together. Configurations are important for two reasons, first, to make right use of service components, the system must be configured correctly, second, some architecture properties are directly related to system configurations. For example, if all communications between clients and servers must go through a single security checker, system performance will suffer because of the bottleneck. • Interaction Protocols. Usually system components interact with each other using proper protocols to provide certain functions. We are referring to application independent architectural protocols here. Typical examples include two-phase commit protocol used for distributed transaction coordination and various authentication protocols. Interaction protocols are important because, first, even with correct system configuration, we still need to make sure that components work in the right way, second, protocols themselves have influences on architectural properties like livelock free and performance. For example, protocols between clients and servers should require as few network trips as possible for performance reason. 3. Object Services and Frameworks Lots of effort have been spent on building infrastructures to address architectural concerns. The current state of practice relies on following two technologies. Object Services Standard object services like CORBA object services have been proposed. Systems can be built as layered architectures where high level application logic components access low level object services transparently. This approach has been shown to be successful to a certain extent. For example, it has been shown in [3] that it is possible to build application-transparent security using DCE security service. But object services only cover the first artifact we mentioned in section 2, developers still need to write code to correctly configure their systems and to access these services in proper protocols, for example they still need to make sure that client requests are evenly distributed among servers and still need to code the two-phase commit process. Usually these code are mingled with application logic code and are redeveloped again and again from project to project. Frameworks Frameworks are a promising technology for reifying proven software designs and implementations, usually these designs and implementations do capture architecture functions and properties. A framework is a reusable, semi-complete application that can be specialized to produce custom applications [7]. Typical framework examples are MacApp, MFC, Java RMI and CORBA. Frameworks are able to capture three system artifacts mentioned in section 2 by acting as a backbone which connects service components and dictates proper system configurations. But the main problem with frameworks is that they are targeted at specific domains because usually part of the business logic is moved into frameworks themselves. As a consequence frameworks are very expensive to build and are not reusable across different domains [7]. So if we think of object services and frameworks as two ends of a spectrum, a better technology is something in the middle. We want to build reusable infrastructures to address architectural concerns without incorporating business logic.